GraphRAG 概览与查询
GraphRAG（Microsoft）在索引阶段用 LLM 从文本抽实体与关系、建知识图谱并做社区摘要，查询阶段按 Global / Local 等模式把结构化上下文塞进 Prompt。本篇讲选型与面试答法；Naive RAG 基线见 RAG 与检索增强，LangChain 向量实现见 [LangChain RAG 实践](/docs/ai/RAG/LangChain RAG 实践)。与图数据库 Neo4j 的异同见该文「GraphRAG 与 Neo4j」专节。
动机：向量 RAG 哪里不够
| 问法类型 | 向量 RAG（top-k 相似段） | GraphRAG |
|---|---|---|
| 「某政策第 3 条说什么？」 | 通常可行 | 也可，但杀鸡用牛刀 |
| 「整个知识库在讲哪几个主题？」 | 难：相似段拼不出全局 | Global Search 强项 |
| 「A 和 B 什么关系、还连到谁？」 | 需碰巧检索到同一段 | 图谱 + Local 更稳 |
| 索引成本 | 相对低 | 高（多轮 LLM 抽图 + 摘要） |
向量 RAG 擅长「找像这个问题的段落」；GraphRAG 擅长「理解整库结构与关系后再答」。
核心思路
原始文档
→ LLM 抽实体、关系（知识图谱）
→ 社区检测（把相关节点聚成簇）
→ 为每个社区生成摘要报告（community reports）
查询时：
→ 按模式选 Global / Local / DRIFT
→ 把相关社区报告、实体邻域等填入 context → LLM 生成
与 Naive RAG 的本质差异：索引产物是图 + 社区摘要，不只是 chunk 向量。
索引产物直觉
| 产物 | 用途 |
|---|---|
entities | 实体节点（人、组织、概念…） |
relationships | 实体间关系边 |
communities | 图上的社区/簇划分 |
community_reports | 每个社区的自然语言摘要，供 Global 查询用 |
索引完成后多为 parquet 等文件；查询 API / CLI 读这些表组装 context。
查询模式
| 模式 | 适合的问题 | 直觉 |
|---|---|---|
| Global Search | 「数据集五大主题？」「整体趋势？」 | 用社区摘要做全库级推理 |
| Local Search | 「Scrooge 是谁、和谁有关？」 | 从某实体出发扩邻域 |
| DRIFT Search | 局部细节 + 更大社区背景 | Local 与社区信息的组合；点到为止 |
面试记忆：Global = 宏观主题，Local = 实体周边。
vs 向量 RAG
| 维度 | 向量 RAG | GraphRAG |
|---|---|---|
| 索引 | embedding + 向量库 | LLM 抽图 + 社区 + 摘要 |
| 成本 | 低 | 高（索引阶段 LLM 调用多） |
| 延迟 | 检索快 | 查询也常更重 |
| 知识更新 | 增删 chunk 即可 | 常需重跑索引流水线 |
| 典型场景 | FAQ、手册、段落问答 | 长叙事、研报、关系网、全局归纳 |
不是「更贵的 embedding」，而是不同的索引与查询结构。
何时选用 GraphRAG
适合：
- 文档长、叙事性强（小说、历史档案、多份报告合集）
- 问题常是「整个库在讲什么」「有哪些主题/派系」
- 关系推理比单段摘录更重要
不必上 GraphRAG：
- 短 FAQ、结构清晰的 Wiki
- 预算紧、索引频繁更新
- 只要段落级引用即可
实践路径：先 Naive 向量 RAG 基线 → 用评测集发现「全局/关系类问题系统性失败」 → 再评估 GraphRAG。
最小 CLI 流程
以 Microsoft GraphRAG 为例（需配置 LLM API，索引阶段会调模型）：
# 1. 初始化项目（生成 settings.yaml 等）
graphrag init --root ./graphrag_project
# 2. 把 .txt / .csv 等放入 input 目录，编辑 settings 中的模型配置
# 3. 跑索引流水线（耗时与费用取决于语料与模型）
graphrag index --root ./graphrag_project
# 4. 查询
graphrag query "What are the top themes in this dataset?" --root ./graphrag_project --method global
graphrag query "Who is Scrooge and what are his main relationships?" --root ./graphrag_project --method local
输出目录常见 output/entities.parquet、communities.parquet、community_reports.parquet 等；理解产物比背命令更重要。
与 Neo4j 的关系
GraphRAG 产出的是图结构索引（实体、关系、社区摘要），Neo4j 是图数据库。二者都涉及「节点 + 边」，但 GraphRAG 管 LLM 抽图 + RAG 查询，Neo4j 管 持久化存储与 Cypher 精确查询，不能互相替代。常见组合：GraphRAG 离线建图后导入 Neo4j 做在线查询；或 Neo4j 存业务图谱 + 向量 RAG 做段落召回。完整对比表见 Neo4j — GraphRAG 与 Neo4j 对比。
与 LangChain 的关系
- LangChain RAG 实践走的是 Document → VectorStore → Retriever，与 GraphRAG 并行路线，不是替代关系。
- GraphRAG 有独立 CLI / Python API；也可在定制流水线里把 GraphRAG 检索结果当 context 交给任意 LLM。
- 生产里常见：大部分问答走向量 RAG，少数全局/分析题走 GraphRAG。
成本与边界
- 索引贵：大语料 + 多轮 LLM，PoC 也要控样本量。
- 读多写少：适合相对静态的知识库；日报级更新需权衡重索引频率。
- 不替代所有 RAG：chunk + embedding 仍是默认首选。
- 评测同样重要：Global 题用「是否覆盖主题关键词」；Local 题看实体与关系是否引用对。
面试速记
- GraphRAG 解决什么？ 向量 RAG 弱的全局归纳、跨文档主题、实体关系与多跳推理。
- 索引三步直觉？ 抽实体关系建图 → 社区划分 → 生成社区摘要报告。
- Global vs Local？ Global 答整库主题/趋势；Local 答特定实体及其关系邻域。
- 何时不用 GraphRAG？ 短 FAQ、频繁更新、只要段落检索、索引预算紧。
- 与 Naive RAG 关系？ 不同索引结构，不是换更好的 embedding；常先向量基线再按失败 case 升级。